pulp_upload runs in a command substitution, so its internal token refresh
only lives in the subshell: the parent shell kept the stale token, killing
the rpm stable-guardrail curl with a 401 at +5 min and forcing every
post-expiry deb upload to re-mint a token and rewrite the pulp-cli config
(seconds per package). Refresh once per loop iteration from the parent
shell instead — the guardrail and the inherited subshell token stay fresh,
and the per-package refresh overhead disappears.

Refs MON-200796

A single limit=1000 page silently truncates once the repository holds more
module packages than the page size (the shared apt-plugins repository is past
5000), flagging delivered packages as missing.

Refs: MON-200796

List the module packages newest first and stop as soon as every expected
package has been seen: the shared plugins repository holds 10k+ module
packages, so an unbounded offset walk is slow, eventually fails server-side,
and the expected packages sit in the tail with the default ordering. The
unexpected-extras report becomes count-based for the same reason.

Refs: MON-200796

grep -q exits on the first match, the printf writer takes a SIGPIPE, and
pipefail turns the pipeline status into 141: every package that IS present
gets flagged missing once the listing outgrows the pipe buffer (the shared
plugins repositories are past 12k module packages). Write the listing to a
file and let grep read the file - no writer left to kill.

Refs: MON-200796

…ng wait)

pulp-cli reads its token once at startup, so its built-in wait dies with
"Authentication failed for tasks_read" as soon as the publication of a large
repository outlives the OIDC token validity (~5 minutes). Start the
publication in the background and poll it with wait_task, which
re-authenticates on every attempt.

Refs: MON-200796

The retry window only covers publication propagation: once a round reads the
published metadata and resolves nothing new while some packages already
resolved, the remaining ones are not part of the publication at all (e.g.
evicted by the retention policy) - report right away instead of burning the
whole 5-minute window, and log the per-round progress.

Refs: MON-200796

One flaky HEAD out of hundreds (content-app/S3 hiccup) must not fail the
whole verification.

Refs: MON-200796

Replace the one-task-per-package association (serialized on the pulp
repository lock) with the batched flow validated at full scale on the
plugins matrix (8 distributions, 675 packages each, delivery + promotion,
zero error):

- delivery: packages are uploaded as repository-less content (create tasks
  parallelize across pulp workers), resolved concurrently, then associated
  with a single repository modify task followed by one publication;
- deb flavor: the first package of each architecture goes through the
  legacy repository code path to materialize the suite associations, the
  rest of the batch gets its PackageReleaseComponent units created
  synchronously before the single modify;
- promotion: the testing packages are listed (latest build only), their
  stable suite associations deduced, and promoted with a single modify
  task instead of one download/re-upload task per package.

Refs: MON-200796

The release_components viewset ships without an access policy upstream
(pulp_deb 3.9, admin-only fallback) and pulpcore offers no way to create
one, so the previous commit's direct listing can never work for the CI
user. Replace it with mechanisms built on endpoints the CI user can read:

- promotion candidates are selected by joining the module content listing
  with the published dists/<testing suite> Packages indexes on sha256
  (fail-closed on index fetch errors), instead of trusting relative_path;
- when every candidate is already published in the stable suite, the
  promotion short-circuits to a republish (idempotent reruns);
- the delivery picks a FRESH package (content not yet in pulp) as the
  legacy representative of each architecture whenever possible: its single
  post-upload association identifies the suite release component exactly;
  reused representatives fall back to a before/after association diff;
- the promotion deduces the stable release component from the same
  before/after diff on its reference package, subtracting the associations
  of not-yet-promoted candidates on reruns.

Refs: MON-200796

The guarded *business-internal distributions answer 403 to anonymous
requests, so the delivery verification could not check the served
metadata or fetchability of business modules (map showed 3/3 present,
0/3 resolvable), and the deb suite-index reads would fail on guarded
suites. Every content-endpoint fetch now goes through content_curl,
which sends the same GitHub OIDC credentials as the api calls (the CI
user holds the guard downloader role, delivery-tooling#232); unguarded
distributions ignore the header.

Refs: MON-200796

Same change as the feature branch (see its history for the rationale).

Refs: MON-200796

Refs: MON-200796

…etry

Align with centreon-plugins: convergent reruns of an interrupted deb
promotion (stable membership from the repository version for dedicated
stable repositories, release component recovery, republish-and-recheck
last resort), segment-aware latest-build selection replacing the plain
string max, and a shared retried start_modify_task helper for every
repository modify call.

Refs: MON-200796

Align with centreon-plugins: under a full-matrix delivery the
publication of a large repository can queue for minutes before its
execution; the ~10 min cap aborted jobs whose task then succeeded.

Refs: MON-200796

Align with centreon-plugins: duplicate suite-association creates on a
rerun are logged as an explicit INFO (the lookup fallback resolves
them); a WARN with the response body remains for real failures.

Refs: MON-200796

Align with centreon-plugins: the api has been observed answering stale
empty pages for content committed seconds earlier; lookup fallbacks now
retry empty results with backoff.

Refs: MON-200796

Align with centreon-plugins: a gateway error page behind a 2xx made the
jq parse silently kill the association subshell under set -e; the
parses are failure-tolerant and fall through to the lookup path.

Refs: MON-200796

Align with centreon-plugins: legacy uploads and repository modify retry
when their task fails on the shared-repository version bookkeeping race
(duplicate version number or retention-cleanup foreign key conflict).

Refs: MON-200796

Align with centreon-plugins: the early exit requires 6 consecutive
stalled rounds and the resolution window covers the content-app cache
TTL, so index lag no longer reads as missing packages.

Refs: MON-200796

Align with centreon-plugins: 'Worker has gone missing' task failures
are retried like the repository-version races, including a publication
re-create.

Refs: MON-200796